Skip to content

Conversation

@picobyte
Copy link

@picobyte picobyte commented Oct 7, 2023

If we want to allow cancel or interrupt, event better describes the action than a job

WIP

If we want to allow cancel or interrupt, event better describes the action than a job
@picobyte
Copy link
Author

picobyte commented Oct 7, 2023

or maybe I should work on the rewrite branch?

@city96
Copy link
Owner

city96 commented Oct 7, 2023

The rewrite branch is probably a better base to start from, it's substantially less jank. As promised, I'll work on it today, so I'd wait a bit before sending PRs.

The reason I used "job" is because that's what the backend uses internally - specifically job_id in the /history and /prompt endpoints.

My current best idea for getting cancel to work is to simply have a node that clears all IDs that start with netdist-, unless there's a way to notify all (already executed/pending/etc) custom nodes about when a workflow is interrupted (I don't think there is?.

The queue on remote node could run this clear remote operation automatically as well, though maybe the job_id would need a short UUID part for that so as to still work with multiple people using the same remote backend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants